There are a lot of modern information technology systems that are required to serve continuously, e.g. different kinds of computer and telecommunication networks. These so called critical systems also require tuning and updating, and it should be possible to do without interruptions, or at least with as short service interruption as possible. The traditional solution is to have a working unit and a spare unit. The working unit serves normally, and in case of breakdown or updating of the working unit, the spare unit continues providing services. The spare unit is able to replace the working unit because it comprises the same information as the working unit. Furthermore, requests coming to the working unit are also directed to the spare unit in order to maintain the consistency of the two units.
Let us assume that, for some reason, the spare unit is e.g. replaced with a new spare unit. Naturally, the new spare unit does not contain the same information as the working unit because it has been booted up. After the boot-up, in order to achieve the 2N redundant feature, the new spare unit needs to be loaded e.g. with necessary configuration data from the working unit. The term “warming” in the claims is used by the claims to mean a procedure of restoring information to a new unit.
Static data does not need to be warmed at all. It can be generated by the programs independently (during unit start-up phase). The amount of dynamic data is the key question. If there is only a little amount of dynamic data, no long interruptions are needed because the working unit can be locked during the warming procedure. Otherwise, long locking periods are needed. However, in case of dynamic data, the data may not be copied in small pieces because the dynamic data can change with time.
The traditional way to do the warming procedure is to lock both the working unit and the spare unit, and copy all the data to the spare unit in one pass. By locking both units, the spare unit will become identical with the working unit. This means that incoming configuration requests have to be queued or acknowledged with a negative status. Negative status refers to a situation where configuration requests cannot be processed.
In both cases, new configurations cannot be created during a long period of time because the transferring capacity between the working unit and the spare unit is limited.
The locking of the working unit causes an interruption in the service. Blocked requests can be rejected, queued or redirected to other unit(s). The duration of the interruption depends on the amount of the data needed to be copied. The problem of the copying in one pass is the time needed for the warming procedure. In case of large dynamic data, the service interruption is considered to be too long. One solution is to have greater bandwidth between the working unit and spare unit to make the data transfer faster.
Another solution for shortening the locking time can be partitioning the warming data into small blocks, and lock only one block at a time. If the configuration action depends on large amount of dynamic data, this approach is not an appropriate solution to be used. Furthermore, if the configuration action causes changes in the various parts of the dynamic data, the partitioning of the warming procedure gets more complicated and warming in small blocks will be very hard to implement.
Yet another solution to implement warming is the following. A copy of the dynamic data can be gathered by an external party which, in the first place, requests configuration actions. Then it's up to this party and the spare unit to get the spare unit up-to-date by using the gathered data. The working unit is not needed to take part in this procedure. This approach has its problems though: a copy of all dynamic data is needed to be stored in some central place. Also some kind of locking is needed for the copying of the data.